C/C++ Users Group Library 1996 July

home *** CD-ROM | disk | FTP | other *** search

/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_300 / 323_01 / adv.doc < prev next >

Wrap

Text File | 1990-08-04 | 12.8 KB | 391 lines

Adventure Guidelines ==================== These guidelines reflect the author's personal philosophy to adventures, so there is naturally a bias in favor of certain factors and against others. This is not to say that some factors are "bad", since what one person finds frustrating another would find challenging, and vice versa. No adventure can include all the guidelines, especially when some of the guidelines seem to contradict each other. Also, for every guideline there will be numerous exceptions and special cases. What it comes down to is this: be aware of the underlying issues, and follow or break the guidelines according to your style. Your are the creator of the adventure. Topics covered: - Theme - Plot - Puzzles - Locations - Objects - Mechanics - Parser Theme ----- Be bold and inventive. - Adventures can take place anywhere. Use sub-themes. - Add variety to adventure. - Can be very different set of locations, or related sets (e.g. different worlds, or just different stores). The theme should permeate throughout the adventure. Plot ---- An adventure can present several featrues to the player (listed in order of decreasing importance): - a goal to be accomplished - puzzles to be solved - interaction with the adventure world - a story - pictures Have events happen to carry the story along. - Events don't have to be linear in occurrence. - An event could occur to sidetrack the player. - The adventure world shouldn't be too static. Have alternative plots, endings, or even objectives. - Player selects which story line, or adv. randomly picks one. - Player, as he plays, selects his own destiny, with some puzzles applying to different scenarios. Have a thorough background. - Work out the history of the adventure world that explains each object and character, and details the events before the adventure began. - This background will provide the foundation and basis for the adventure's puzzles and situations. - Although the full history is available, don't have to explain everything. Have a step by step build up to some climax or high point. Something exciting should happen at this point. Puzzles ------- Don't have irreversible puzzles. - More than just one chance to do something. - Important objects can not be destroyed. - No irrecoverable situations. Have several solutions to problems. - Avoid the bad thinking "if I spend time putting it in, then everyone must encounter it". - If a player's action accomplishes something, or at least generates a non-canned response, then the player is more satisfied than a canned response or a "I don't know how to do that" message. - In order of decreasing satisfaction, the type of responses are: - action towards goal - action irrelevant to goal - non-canned response - canned response - unanticipated command - not recognizing word Have solutions with a moral quality or sense of purpose. - Avoid bland do-it-because-you-can type of puzzles. - Could have some emotions attached (e.g. rescue a fuzzy animal). - The player should feel a sense of accomplishment. Have fair and "logical" puzzles. - Puzzles can be as different and wild as the imagination, but they must be logically solvable given the circumstances that the player is in. - The puzzles should fit into the overall theme. Sometimes puzzles can simply be reworded to fit into a particular theme. Locations --------- No illogical mazes, mixed-up directions, or un-mappable locations. - A maze should be a real maze, not a set of impossible-to-map rooms. - Even if the adventure consists of independent sets of locations, there should still be a logical layout to the map. No empty or useless rooms. - A location just for the sake of completeness may add to the theme, but from the player's point of view it is disappointing. - This is especially true if the descriptions of the rooms are short, since for long descriptions the location can significantly add to the mood and feel of the adventrue. Objects ------- Have an info source. - Gives backgound info on objects/characters. - Gives hints / how to use objects. - Plot development. - Humour. Have "helper" characters. - act as an ally to the player - e.g. The vendor in Intrepid, Thunderhawk in Gems Have character interaction. - Fake conversations. - Puzzles involving other characters. - Getting hints from characters. - Characters which follow the player. Mechanics --------- No deaths. - Use a warning message for experimental/avoidable deaths. - No unavoidable dangers / always have warnings. - "If the player can be killed, then he can be warned of the danger". No dwindling vital resource constraints (battery, air, time). - As part of a puzzle, having to refill a resource is alright. - As a limiting factor which can halt an adventure and force a player to restart, it is an unnecessary obstacle. Have a high carry limit, or no limit at all. - Object count dependent. - Object size/weight dependent. Have a narrator with a consistent personality and knowledge level. - An all-knowing entity watching from above. - Someone moving with the player. - A puppet controlled by the player (uses 'I' in narrative). Have some factors in the adventure that are random with each game. - e.g. safe combination, color, a true maze Parser ------ Have a large vocabulary. - Provide synonyms for words, especially for verbs. Have an appropriate parser. - If the adventure requires many verb-noun-object constructs, then having to use verb-noun commands with auxillary prompts becomes cumbersome. - A more advanced parser can give more interesting puzzles and a more natural feel to the adventure, but will require more work to handle other responses. - Parser types, in increasing order of complexity: - "verb noun" - "verb [article] noun" - "verb [article] [ajective]* noun" - "verb [article] [ajective]* noun [prep [article] [adjective]* noun]" Further Reading --------------- Articles about adventures, as oppose to reviews of adventures, are becoming quite rare. Back issues of hobbyist-type computer magazines will be the best place to look for them. Betz, David. "An Adventure Authoring System." Byte, May 1987, pp. 135-142. Blank, Marc S. "How To Fit A Large Program Into A Small Machine." Creative Computing, July 1980, pp. 80-87. Bridge, Tony. Atari Adventures. Sunshine Books, 1984. Buckles, Mary Ann. "Interactive Fiction As Literature." Byte, May 1987, pp. 135-142. Crayne, Dian. "Do It Yourself Adventures." PC Magazine, September 1983, pp. 266-276. Dacosta, Frank. Writing BASIC Adventure Programs For The TRS-80. TAB Books, 1982. Grace, Mike. Commodore 64 Adventures. Sunshine Books, 1983. Hassett, Greg. "Writing Your Own Adventure." Creative Computing, July 1980, pp. 88-90. Lebling, David. "Zork And The Future Of Computerized Fantasy Simulations." Byte, December 1980, pp. 172-182. Liddil, Bob. "On The Road To Adventure." Byte, December 1980, pp. 158-170. Liddil, Bob. The Captain 80 Book of BASIC Adventures. Northwest Publishing Inc., 1981. McGath, Gary. Compute!'s Guide to Adventure Games. Compute! Publishing Inc., 1984. Plamondon, Robert. "Putting Adventure In Adventure Games." Creative Computing, August 1981, pp. 70-76. Prussing, Scott. "The Next Step: Introducing The Participant Novel." PC Magazine, December 1982, pp. 296-300. ======================================================================== Summary of Adventure Readings ======================================================================== ------------------------------------------------------------------------ Atari Adventures ------------------------------------------------------------------------ Source: Bridge, Tony. Atari Adventures. Sunshine Books, 1984. Playing adventures - look around every location in as much detail as possible - everything has a purpose - exercise extreme caution at all times - always save your position if in doubt ------------------------------------------------------------------------ Compute!'s Guide to Adventure Games. ------------------------------------------------------------------------ Source: McGath, Gary. Compute!'s Guide to Adventure Games. Compute! Publishing Inc., 1984. What makes a good adventure - player shouldn't have to solve the program, therefore: - good parser - large vocabulary - good error handling - watch for grammar, spelling, etc. - responses shouldn't be misleading - graphics should at least supply additional fact or expand on text - can't be too slow - quality in them, story, and puzzles. - adventure should fit together as a self-consistent world - elements foreign to the theme shouldn't be present (e.g. magic in sf) - puzzles should be logical - dangers should be preceded by warnings, not by "learn from dying" Playing adventures - draw a map - map mazes by dropping objects - go everywhere (e.g. some walls are penetrable) - examine everything - think of possible uses for objects - watch for interaction between objects (e.g. same colour lock and key) - figure out what you need to solve a problem (e.g if you need a pin, then anything pin-like might work as well) - read descriptions carefully - make use of negative repsonses - make use of the SAVE feature, if present - if you're stumped on one problem, switch to another - answer rhetorical questions (e.g. do you really want to kill the dragon with your bare hands?) - experiment - make use of the command handler's capabilities - don't overestimate the program's abilities (listen xxx-->nothing might be because listen doesn't accept nouns) - if a command doesn't work, try rephrasing it - think of literay allusions - get help Writing an adventure - complex command handling is useful - background activity is interesting - key to a good adventure is its puzzles; can't be too hard or too easy - puzzles should be somehow interconnected; everything works towards the final goal - the player should have a sense of progress - design the adventure before coding Improvements to the adventure genre - better writing; (e.g. sci-fi writers doing adventures) - other IO methods (e.g. voice, video disk, speech, etc.) - bigger decision trees to get more: permissible actions, crucial decisions, background events, endings - more realistic presentation of the environment - increased sense of continuous action - better simulation of characters - wider range of alternatives ------------------------------------------------------------------------ Commodore 64 Adventures. ------------------------------------------------------------------------ Source: Grace, Mike. Commodore 64 Adventures. Sunshine Books, 1983. Playing adventures - make a map - pick up everything - examine everything Writing adventures - the story is very important - steps in writing - select the environment (fantasy, horror, sf, ...) - choose a quest or goal (find treasure, escape from wizard, ...) - decide on the role of the player - select the main characters - write a synopsis of the story - draw a simplified map with a few basic locations - storyboard the plot Select the environment - fantasy: Tolkien, swords and sorcery, magic - horror: dracula, haunted house, decent to Hell to reclaim your soul, escape from voodoo islands - comic strip - conventional: spies, crime, survival on island - sf Choose a quest or goal - choose before doing story - expand to have subplots - don't have to work out fine details yet Role of hero - two main choices: - player acts as himself thrown into the fantasy world - player takes on the role of the fantasy hero Other characters - accomplices, people to rescue, villans, assorted type to add local colour, red herrings, clue-givers - could ask for sex of player, than adjust characters accordingly (if male, rescue princess; if female, rescue prince) Write synopsis of story - ideas could come anytime - slowly add refinements and improvements Drawing the initial map - to get some idea of the geographical relation of the locations, draw basic map - keep number of locations small; can expand later - can put the map in tabular form: location # name object/peril Storyboard the plot - similar to the movies/comic book technique - imagine layout of text on screen, and player's possible responses - story board descriptions can be longer than actual text LOCATION: .... ...... ..... command> ... .....